home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970626-19970929 / 000170_news@newsmaster….columbia.edu _Fri Aug 15 17:42:50 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA20873
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 15 Aug 1997 17:42:49 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id RAA23233
  7.     for kermit.misc@watsun; Fri, 15 Aug 1997 17:42:49 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit cyclic error problem
  12. Message-ID: <hplveE5fxIya@cc.usu.edu>
  13. Date: 14 Aug 97 14:06:13 MDT
  14. References: <u3eodau35.fsf@donal.kintailrd>
  15. Organization: Utah State University
  16. Lines: 52
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:7475
  18.  
  19. In article <u3eodau35.fsf@donal.kintailrd>, Bruce Cook <BC3-AU@bigfoot.com> writes:
  20. > I have a link between a Winnt4.0SP5 machine with Kermit-95v1.1.12 16550A
  21. > and a DOS machine with MSkermit-3.15 16450.
  22. > 
  23. > The link is running a 115200, 32 windows, 360 byte packets, block=3.
  24.  
  25.     32 * 360 = 11.5KB of packet buffer space.
  26.     Try 4 window slots; more is not helping at all because the
  27. line delay is still short. Most importantly, ensure hardware flow
  28. control is active across the entire link, because I strongly suspect
  29. the modem link plus serial port buffering within NT is dropping bytes 
  30. from overflow.
  31.     For others reading along, sliding windows says how many packets
  32. are allowed to be transmitted before an ACK for the oldest arrives. The
  33. time for that ACK to arrive is primarily transmission path delay plus
  34. some delay in the receiving host. It would be an unusual path needing
  35. or even using as many as 8 packet slots, unless those packets were
  36. tiny (a bad idea). Going across the country on a decent Internet link
  37. (25KByte/sec rate, not using modems) uses a max of 6 packet slots in my 
  38. experiments, and the faster the link the more packets go out to soak up 
  39. the delay time (or, equivalently, to keep the transmit wire full).
  40.     Your modem link is NOT running at 115Kbps. The connection between
  41. your modem and the computer might, but the telephone company wiring makes 
  42. the data flow at very much slower rates. 33Kbits/sec (say 4KBytes/sec)
  43. is doing well for modems. And there resides the imperative to provide
  44. hardware flow control, to avoid overrunning the slow part of the system.
  45.     Joe D.
  46.  
  47. > 
  48. > When receiveing, I get an error every n packets where n is the number
  49. > of windows. (I've adjusted windows from 4 to 32).  This is giving
  50. > me an obvious throughput problem at 4 windows (25% error rate).
  51. > 
  52. > The packet size is so low, because of the line reliability, which
  53. > realy suprises me.  Speed doesn't realy make much difference.
  54. > 
  55. > The msk315 client is showing n of 32 windows, and every time n reaches
  56. > 32, a retry happens, and n is reset back to 1.  This cycle happens
  57. > no matter how many windows I have set up, obviously 32 windows gives
  58. > me a lower error percentage.
  59. > 
  60. > Anyone got any ideas as to what's going on ?
  61. > 
  62. > 
  63. > -- 
  64. > ...BRU
  65. > 
  66. > Bruce Cook,  Synonet Corp.
  67. > E-Mail: bcook@wantree.com.au
  68. > Phone:  +061 15 999 330
  69. > 
  70. >